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DETAILED ACTION 



Introduction 

1 . Claims 1-19 of U.S. Application 09/510,203 filed on 2/22/00 are presented for 
examination. Prosecution has been reopened, and new art has been applied. 



2. Examiner interprets "design module" according to Applicants' definition in the 
specification (p.1, lines 18-22): "System-level integration relies on reuse of 
previously created designs, either from within an enterprise or from a commercial 
provider. The engineering community sometimes refers to these previously 
created designs as 'design modules', 'cores', or IP 1 (intellectual property)." 

3. Examiner interprets "functional design element" according to Applicant's 
embodiments in the specification (p.6, lines 31-33): "For example, HDL design 
constructs are traced from high-level design to design elements. In schematic C, 
any changes made by a translation tool are tracked." 

4. Examiner interprets "design script" according to Applicant's embodiments in the 
specification (p.6, lines 31-33): (p.7, line 34 to p.8, line 2): "A design script is also 
created by the designer. The design script contains the directives that specify 
which tools to run, the order in which the tools are to run, as well as options and 
environment variables for the tools. The design script is stored in a separate file." 



Claim Interpretations 
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5. Examiner interprets "link" according to definition 3.a in the American Heritage® 
Dictionary, 4 th Ed. ( © 2000 - "An association; a relationship." 

6. Examiner interprets "database" according to the definition in the American 
Heritage® Dictionary, 4 th Ed., © 2000 - "A collection of data arranged for ease 
and speed of search and retrieval." 

7. Examiner interprets that comments interspersed in VHDL or Verilog source code 
constitute one type of "documentation elements" 

Allowable Subject Matter 

8. The 16-step flowchart displayed in Fig. 3, would be allowable if written as a 
"specific sequence of steps" claim using "means for" or "step for" language. 

Claim Objections 

9. Claims 7-8, 10, 12, and 15 are objected to as being dependent upon a rejected 
base claim, but would be allowable if rewritten in independent form including all 
of the limitations of the base claim and all intervening claims. 



10. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 



Claim Rejections - 35 USC § 102 



States. 
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1 1 .The prior art used for these rejections is as follows: 

12. Bhasker, J., Verilog© HDL Synthesis: A Practical Primer. Chapter 5, 
"Verification", ©1998. (Henceforth referred to as "Bhasker"). 

13. The claim rejections are hereby summarized for Applicant's convenience. The 
detailed rejections follow. 

14. Claims 1-6, 9, 11, 13, 14, and 16-19 are rejected under 35 U.S.C. 102(b) as 
being anticipated by Bhasker. 

1 5. In regards to Claim 1 , Bhasker teaches the following limitations: 

1 . A computer-implemented method for developing a reusable 
electronic circuit design module, wherein the design module 
is comprised of one or more functional design elements 
comprising the design module, comprising: 

entering the functional design elements into a 
database; 

(Bhasker, especially: pp. 174-1 75 and Figs. 5-2 and 5-3) 

Bhasker teaches (p. 174) that "One approach to verifying functionality is to 
simulate the netlist with the same set of stimulus as used during design 
model simulation, save the results in a results file and compare to see if 
the results are identical". 

Examiner interprets that the design model and netlists are inherently 
stored in files, because the synthesis process would not function 
otherwise. 

Examiner interprets that a file fits the dictionary definition of database (see 
"Claim Interpretations" section). 

entering documentation elements into the database; 
(Bhasker, especially: pp. 174-1 75, 178 and Figs. 5-2 and 5-3) 

Bhasker teaches (p. 175) that "Another approach is to write a test bench". 

Bhasker's example test bench (pp. 175-1 76) and example functional 
design element (p. 178) contains comment lines. (These lines begin with 
the 7/" symbol). 
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Examiner interprets that these comments constitute a type of 
"documentation elements" in the files / "database", (see "Claim 
Interpretations" section). 

linking the functional design elements with selected 
ones of the documentation elements; 

(Bhasker, especially: pp. 174-1 75, 178 and Figs. 5-2 and 5-3) 

Examiner interprets that the embedding of comments in the source code 
files constitutes a form of "linking" as defined in the dictionary, (see "Claim 
Interpretations" section). 

simulating a testbench with the design module, whereby 
simulation results are generated; 

(Bhasker, especially: pp.1 74-1 75, 178 and Figs. 5-2 and 5-3) 

Bhasker teaches (p.174) that "One approach to verifying functionality is to 
simulate the netlist with the same set of stimulus as used during design 
model simulation, save the results in a results file and compare to see if 
the results are identical". 

storing the simulation results in the database; and 
(Bhasker, especially: pp. 174-1 75 and Figs. 5-2 and 5-3) 

Bhasker teaches (p. 174) that "One approach to verifying functionality is to 
simulate the netlist with the same set of stimulus as used during design 
model simulation, save the results in a results file and compare to see if 
the results are identical". 

Bhasker expressly teaches that the simulation results are stored in a 
results file. Examiner interprets that a file fits the dictionary definition of 
database (see "Claim Interpretations" section). 

linking the simulation results with the functional 
design elements. 

(Bhasker, especially: pp. 174-1 75 and Figs. 5-2 and 5-3) 

Bhasker teaches (p.1 74) that "One approach to verifying functionality is to 
simulate the netlist with the same set of stimulus as used during design 
model simulation, save the results in a results file and compare to see if 
the results are identical". 

Examiner interprets that the comparison of the results in the results file 
(see Fig. 5-2, Fig. 5-3) finds "links" between the simulation results and the 
functional design elements. 
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16. In regards to Claim 2, Bhasker teaches the following limitations: 

2. The method of claim 1 , further comprising: 
translating the functional design elements into a 

netlist; and 

(Bhasker, especially: p. 174, Figs.5-1 and 5-2) 

linking elements of the netlist with selected ones of 
the functional design elements. 
(Bhasker, especially: p. 174, Figs.5-1 and 5-2) 

Bhasker teaches (p. 174) that "One approach to verifying functionality is to 
simulate the netlist with the same set of stimulus as used during design 
model simulation, save the results in a results file and compare to see if 
the results are identical". 

Examiner interprets that the comparison of the results in the results file 
(see Fig. 5-2, Fig. 5-3) finds "links" between the simulation results and the 
functional design elements. 

17. In regards to Claim 3, Bhasker teaches the following limitations: 

3. The method of claim 2, further comprising: 
translating the functional design elements into a 
physical implementation; and 

(Bhasker, especially: pp.1 73-1 74 and Figs. 5-1, 5-2, and 5-3) 

Examiner interprets that Bhasker's teaching of synthesizing the netlist 
from the design model corresponds to applicants' "translating the 
functional design into a physical implementation." 

linking elements of the physical implementation with 
selected ones of the functional design elements. 
(Bhasker, especially: pp. 173-1 74 and Figs. 5-1, 5-2, and 5-3) 

Examiner interprets that the comparison of the results in the results file 
(see Fig. 5-2, Fig. 5-3) finds "links" between the simulation results and the 
functional design elements. 

18. In regards to Claim 4, Bhasker teaches the following limitations: 

4. The method of claim 1 , further comprising: 
entering simulation elements in the database; and 

(Bhasker, especially: p. 174, Figs.5-1 and 5-2) 

linking the simulation elements to associated ones of 
the design elements. 

(Bhasker, especially: p. 174, Figs.5-1 and 5-2) 
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Bhasker teaches (p. 174) that "One approach to verifying functionality is to 
simulate the netlist with the same set of stimulus as used during design 
model simulation, save the results in a results file and compare to see if 
the results are identical". 

Examiner interprets that the comparison of the results in the results file 
(see Fig. 5-2, Fig. 5-3) finds "links" between the simulation results and the 
functional design elements. 

19. In regards to Claim 5, Bhasker teaches the following limitations: 

5. The method of claim 4, further comprising: 
entering documentation for a design script in the 

database; and 

(Bhasker, especially: pp. 174-1 75, Figs.5-2 and 5-3) 

Examiner finds that the flow charts shown in Figs. 5-2 to 5-3 correspond to 
"design scripts". The code on pp.1 75-1 76 implements the flow chart of 
Fig. 5-3, and the comments embedded in the code constitute 
documentation of the of the flow chart / "design script". 

linking the documentation of the design script to the 
design elements comprising the design module. 
(Bhasker, especially: pp. 174-1 75, Figs.5-2 and 5-3) 

The design script comments (p. 175) are linked to the design elements 
because the comments and the instantiation of the design module (see 
design script, p. 175) are in the same file. 

20. In regards to Claim 6, Bhasker teaches the following limitations: 

6. The method of claim 4, further comprising: 
entering documentation for the simulation elements in 

the database; and 

(Bhasker, especially: p. 178, example of synthesized netlist) 

linking the documentation for the simulation elements 
with associated ones of the simulation elements. 
(Bhasker, especially: p. 178, example of synthesized netlist) 

The documentation and the simulated elements are linked by being placed 
in the same file. 

21 . In regards to Claim 9, Bhasker teaches the following limitations: 



9. 



The method of claim 1, further comprising: 
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inspecting the functional design elements for 
undesirable design characteristics; and 
(Bhasker, especially: pp. 178-1 81) 

reporting the undesirable design characteristics found 
in the functional design elements. 
(Bhasker, especially: pp. 178-1 81) 

Bhasker teaches the inspecting for and reporting of unconnected ports 
(pp. 178-1 79) and missing latches (pp. 179-1 81). 

22. In regards to Claim 1 1 , Bhasker teaches the following limitations: 

1 1 . The method of claim 9, further comprising: 

inspecting the functional design elements for adherence 
to predefined design rules; and 
(Bhasker, especially: pp.178-181) 

reporting violations of the design rules. 
(Bhasker, especially: pp.178-181) 

Bhasker teaches the inspecting for and reporting of violations of 
predefined design rules pertaining to unconnected ports (pp. 178-1 79) and 
missing latches (pp.1 79-1 81). 

23. In regards to Claim 13, Bhasker does not expressly teach the following 
limitations: 

1 3. The method of claim 9 f further comprising: 

monitoring changes made to the functional design 
elements; and 

(Bhasker, especially: pp.178-181) 

indicating which of the functional design elements are 
dependent on the changes. 
(Bhasker, especially: pp.178-181) 

Bhasker teaches the inspecting for and reporting of unconnected ports 
(pp. 178-1 79) and missing latches (pp. 179-1 81). 

Bhasker teaches (p. 179) that: "A good synthesis system will issue warning 
messages about a value used before being assigned (such as variable C 
in the module AOI22. Pay attention to these warnings." 
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24. In regards to Claim 14, Bhasker teaches the following limitations: 

14. The method of claim 1, further comprising: 

translating the functional design elements into a 
physical implementation; and 

(Bhasker, especially: pp. 173-1 75 and Figs. 5-1, 5-2 and 5-3) 

The synthesis of the design model into a netlist corresponds to "translating 
functional design elements into a physical implementation" 

linking elements of the physical implementation with 
selected ones of the functional design elements. 
(Bhasker, especially: pp. 173-1 75 and Figs. 5-1, 5-2 and 5-3) 

Bhasker teaches (p. 174) that "One approach to verifying functionality is to 
simulate the netlist with the same set of stimulus as used during design 
model simulation, save the results in a results file and compare to see if 
the results are identical". 

The comparison of simulation results of the design model and netlist 
corresponds to "linking elements of the physical implementation with 
selected ones of the functional design elements." 

25. In regards to Claim 16, Bhasker teaches the following limitations: 

1 6. The method of claim 1 , further comprising displaying 
the functional design elements linked to errors in the 
simulation results. 

(Bhasker, especially: pp. 174-1 75 and Figs. 5-2 and 5-3) 

Bhasker teaches (p. 174) that "One approach to verifying functionality is to 
simulate the netlist with the same set of stimulus as used during design 
model simulation, save the results in a results file and compare to see if 
the results are identical". 

26. In regards to Claim 17, Bhasker teaches the following limitations: 

17. The method of claim 16, further comprising displaying 
documentation elements associated with errors in the 
simulation results. 

(Bhasker, especially: pp.1 74-1 75 and Figs. 5-2 and 5-3) 

Bhasker teaches (p. 174) that "One approach to verifying functionality is to 
simulate the netlist with the same set of stimulus as used during design 
model simulation, save the results in a results file and compare to see if 
the results are identical". 
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27. In regards to Claim 18, Bhasker teaches the following limitations: 

18. An apparatus for developing a reusable electronic 
circuit design module, wherein the design module is 
comprised of one or more functional design elements 
comprising the design module, comprising: 

means for entering the functional design elements into 
a database; 

(Bhasker, especially: pp. 174-1 75 and Figs. 5-2 and 5-3) 

Bhasker teaches (p.174) that "One approach to verifying functionality is to 
simulate the netlist with the same set of stimulus as used during design 
model simulation, save the results in a results file and compare to see if 
the results are identical". 

Examiner interprets that the design model and netlists are inherently 
stored in files, because the synthesis process would not function 
otherwise. 

Examiner interprets that a file fits the dictionary definition of database (see 
"Claim Interpretations" section). 

means for entering documentation elements into the 
database; 

(Bhasker, especially: pp. 174-1 75, 178 and Figs. 5-2 and 5-3) 

Bhasker teaches (p. 175) that "Another approach is to write a test bench". 

Bhasker' s example test bench (pp. 175-1 76) and example functional 
design element (p. 178) contains comment lines. (These lines begin with 
the 7/" symbol). 

Examiner interprets that these comments constitute a type of 
"documentation elements" in the files / "database", (see "Claim 
Interpretations" section). 

means for linking the functional design elements with 
selected ones of the documentation elements; 
(Bhasker, especially: pp. 174-1 75, 178 and Figs. 5-2 and 5-3) 

Examiner interprets that the embedding of comments in the source code 
files constitutes a form of "linking" as defined in the dictionary, (see "Claim 
Interpretations" section). 

means for simulating a testbench with the design 
module, whereby simulation results are generated; 
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(Bhasker, especially: pp.1 74-1 75, 178 and Figs. 5-2 and 5-3) 

Bhasker teaches (p. 174) that "One approach to verifying functionality is to 
simulate the netlist with the same set of stimulus as used during design 
model simulation, save the results in a results file and compare to see if 
the results are identical". 

means for storing the simulation results in the. 
database; and 

(Bhasker, especially: pp. 174-1 75 and Figs. 5-2 and 5-3) 

Bhasker teaches (p. 174) that "One approach to verifying functionality is to 
simulate the netlist with the same set of stimulus as used during design 
model simulation, save the results in a results file and compare to see if 
the results are identical". 

Bhasker expressly teaches that the simulation results are stored in a 
results file. Examiner interprets that a file fits the dictionary definition of 
database (see "Claim Interpretations" section). 

means for linking the simulation results with the 
functional design elements. 

(Bhasker, especially: pp. 174-1 75 and Figs. 5-2 and 5-3) 

Bhasker teaches (p.174) that "One approach to verifying functionality is to 
simulate the netlist with the same set of stimulus as used during design 
model simulation, save the results in a results file and compare to see if 
the results are identical". 

Examiner interprets that the comparison of the results in the results file 
(see Fig. 5-2, Fig. 5-3) finds "links" between the simulation results and the 
functional design elements. 

28. In regards to Claim 19, Bhasker teaches the following limitations: 

19. A system for developing a reusable electronic circuit 
design module, wherein the design module is comprised of one 
or more functional design elements comprising the design 
module, comprising: 

a database arranged for storage of the design elements 
and documentation elements; 

(Bhasker, especially: pp. 174-1 75 and Figs. 5-2 and 5-3) 

Bhasker teaches (p.174) that "One approach to verifying functionality is to 
simulate the netlist with the same set of stimulus as used during design 
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model simulation, save the results in a results file and compare to see if 
the results are identical". 

Bhasker teaches (p. 175) that "Another approach is to write a test bench". 

Bhasker 1 s example test bench (pp. 175-1 76) and example functional 
design element (p.178) contains comment lines. (These lines begin with 
the 7/" symbol). 

Examiner interprets that these comments constitute a type of 
"documentation elements" in the files / "database", (see "Claim 
Interpretations" section). 

a design inspector coupled to the database, the design 
inspector configured and arranged to link the functional 
design elements with selected ones of the documentation 
elements; 

(Bhasker, especially: pp. 174-1 75, 178 and Figs. 5-2 and 5-3) 

Examiner interprets that the embedding of comments in the design model 
files constitutes a form of "linking" as defined in the dictionary, (see "Claim 
Interpretations" section). 

a debugging-support module coupled to the simulator and 
to the database, the debugging-support module configured and 
arranged to generate a netlist from the design module, 
wherein the netlist is suitable for simulation; 
(Bhasker, especially: pp. 173-1 75 and Figs. 5-1, 5-2 and 5-3) 

Bhasker expressly teaches the use of a "synthesis process" that produces 
a netlist from a design model. (See Figs. 5-1 , 5-2 and 5-3). Bhasker also 
teaches that the netlist is suitable for simulation (see Figs.5-2 and 5-3) 

a functional simulator coupled to the debugging-support 
module, the simulator configured and arranged to simulate a 
testbench with the design module, whereby simulation results 
are generated; and 

(Bhasker, especially: p. 175 and Fig. 5-3) 

Bhasker teaches (p. 175) that "Another approach is to write a test bench". 

Fig. 5-3 shows that a simulator is configured to simulate a testbench with 
the design module. 

wherein the debugging-support module is further 
configured and arranged to store the simulation results in 
the database and link the simulation results with the 
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functional design elements. 

(Bhasker, especially: pp. 174-1 75 and Figs. 5-2 and 5-3) 

Bhasker teaches (p. 175) that "Another approach is to write a test bench; a 
test bench is a model written in Verilog HDL that applies stimulus, 
compares the output responses, and reports any functional mismatches". 

Examiner interprets that a "report" consists of a file, and that the results 
inherently link the simulation results with the design elements. 



Any inquiry concerning this communication or earlier communications from 
the examiner should be directed to Ayal I. Sharon whose telephone number is 
(703) 306-0297. The examiner can normally be reached on Monday through 
Thursday, and the first Friday of a biweek, 8:30 am - 5:30 pm. 

If attempts to reach the examiner by telephone are unsuccessful, the 

examiner's supervisor, Kevin Teska can be reached on (703) 305-9704. Any 

response to this office action should be mailed to: 

Director of Patents and Trademarks 
Washington, DC 20231 

Hand-delivered responses should be brought to the following office: 

4 th floor receptionist's office 
Crystal Park 2 
2121 Crystal Drive 
Arlington, VA 

Fax: (703) 872-9306 



Correspondence Information 
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Any inquiry of a general nature or relating to the status of this application 
or proceeding should be directed to the receptionist, whose telephone number is: 
(703) 305-3900. 

Ayal I. Sharon 
Art Unit 2123 
July 23, 2004 




